home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 894 < prev    next >
Encoding:
Text File  |  1996-08-05  |  1.5 KB  |  56 lines
  1. Path: lrz-muenchen.de!sun2!ua302aa
  2. From: ua302aa@sun2.lrz-muenchen.de (Kurt Watzka)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: A problem with fprintf
  5. Date: 9 Jan 1996 14:29:18 GMT
  6. Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
  7. Distribution: world
  8. Message-ID: <4ctu3u$8t9@sparcserver.lrz-muenchen.de>
  9. References: <4cs8ie$5ru@no-names.nerdc.ufl.edu> <4csdt4$mcn@castle.nando.net> <4cth3m$1c0@yarrow.wt.com.au>
  10. NNTP-Posting-Host: sun2.lrz-muenchen.de
  11.  
  12. bvarley@yarrow.wt.com.au (bruce varley) writes:
  13.  
  14. >In a formal sense the debugger is right. 'src' is not the same as a
  15. >pointer to a string. &src[0] is closer to being formally right, if src
  16. >is type char. If the debugger is REALLY finicky, it might go off
  17. >hunting for the null and spit the dummy if it doesn't find it.
  18.  
  19. If src is an array, there is no difference between the expression
  20. "src" and the expression "&src[0]" if those expressions are used
  21. as arguments in a function call.
  22.  
  23. >One solution is to use pointers. char* is the right way to point to
  24. >the string to be output. 
  25.  
  26. >Not all compilers are this fussy.
  27.  
  28. Compilers that pass different pointer to func() in one of the
  29. following three situations are not extremely fuzzy, they are
  30. plain wrong:
  31.  
  32.   char arg[5];
  33.  
  34. Situation 1:
  35.  
  36.   func(arg);
  37.  
  38. Situation 2:
  39.  
  40.   func(&arg[0]);
  41.  
  42. Situation 3:
  43.  
  44.   {
  45.      char *p;
  46.  
  47.      p = &arg[0];
  48.      func(p);
  49.   }
  50.  
  51. Kurt
  52. --
  53. | Kurt Watzka                             Phone : +49-89-2180-6254
  54. | watzka@stat.uni-muenchen.de
  55. | ua302aa@sunmail.lrz-muenchen.de
  56.